src/main/java/com/example/inflace/global/client/YoutubeAnalyticsApiClient.java (1)

98-107: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Fallback 로그 메시지가 API 호출 실패 상황에서 오해의 소지가 있습니다.

youtubeAnalyticsFallback은 Bulkhead/RateLimiter 거부뿐 아니라 API 호출 자체가 실패(4xx/5xx)한 경우에도 호출됩니다. 현재 로그 메시지 "blocked or failed before execution"는 후자의 경우 실제로는 API 호출이 실행되었음에도 "before execution"으로 표현되어 디버깅 시 혼란을 줄 수 있습니다.

🔧 제안: 로그 메시지 개선

     log.warn("YouTube Analytics API call blocked or failed before execution. googleId={} metrics={} dimensions={}",
             googleId, request.formattedMetricsList(), request.dimensions(), throwable);

-    log.warn("YouTube Analytics API call blocked or failed before execution. googleId={} metrics={} dimensions={}",
-            googleId, request.formattedMetricsList(), request.dimensions(), throwable);
+    log.warn("YouTube Analytics API call rejected or failed. googleId={} metrics={} dimensions={}",
+            googleId, request.formattedMetricsList(), request.dimensions(), throwable);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/example/inflace/global/client/YoutubeAnalyticsApiClient.java`
around lines 98 - 107, The fallback log message in youtubeAnalyticsFallback is
misleading because it says the call was “blocked or failed before execution”
even when the API request actually ran and then failed. Update the log text in
YoutubeAnalyticsApiClient.youtubeAnalyticsFallback to clearly distinguish
pre-execution rejections from downstream API failures, while still logging
googleId, request.formattedMetricsList(), request.dimensions(), and the
throwable for debugging.

src/main/java/com/example/inflace/domain/channel/service/sync/YoutubeChannelAnalyticsFetchService.java (1)

613-619: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

chunked 메서드가 YoutubeDataApiClient에도 동일하게 존재하여 중복됩니다.

그래프 컨텍스트에 따르면 YoutubeDataApiClient.java의 613-619번 라인에 동일한 구현의 private chunked 메서드가 있습니다. 두 클래스에서 같은 유틸리티 로직이 중복되고 있으므로 공용 유틸 클래스로 추출을 고려해 보세요.

♻️ 제안: 공용 유틸 클래스로 추출

-    private <T> List<List<T>> chunked(List<T> values, int size) {
-        List<List<T>> chunks = new ArrayList<>();
-        for (int start = 0; start < values.size(); start += size) {
-            chunks.add(values.subList(start, Math.min(values.size(), start + size)));
-        }
-        return chunks;
-    }

// 예: src/main/java/com/example/inflace/global/util/ListUtils.java
public final class ListUtils {
    private ListUtils() {}
    
    public static <T> List<List<T>> chunked(List<T> values, int size) {
        List<List<T>> chunks = new ArrayList<>();
        for (int start = 0; start < values.size(); start += size) {
            chunks.add(values.subList(start, Math.min(values.size(), start + size)));
        }
        return chunks;
    }
}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/example/inflace/domain/channel/service/sync/YoutubeChannelAnalyticsFetchService.java`
around lines 613 - 619, `chunked` 로직이 `YoutubeChannelAnalyticsFetchService`와
`YoutubeDataApiClient`에 중복되어 있으니, 두 곳의 private 메서드를 공용 유틸로 합치세요. `chunked`를
`ListUtils` 같은 재사용 가능한 클래스의 static 메서드로 추출하고,
`YoutubeChannelAnalyticsFetchService`와 `YoutubeDataApiClient`는 그 공용 메서드를 호출하도록
변경해 중복 구현을 제거하세요.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/main/java/com/example/inflace/global/config/RestClientConfig.java (2)

17-17: 🚀 Performance & Scalability | 🔵 Trivial | 💤 Low value

SimpleClientHttpRequestFactory는 커넥션 풀링을 지원하지 않습니다.

SimpleClientHttpRequestFactory는 내부적으로 HttpURLConnection을 사용하여 요청마다 새 TCP 연결을 생성합니다. 이 PR에서 여러 외부 API 클라이언트가 Bulkhead 기반 가상 스레드 병렬 실행으로 동시 요청을 보내므로, 커넥션 재사용이 성능에 도움이 될 수 있습니다. 프로덕션 환경에서는 JdkClientHttpRequestFactory 또는 HttpComponentsClientHttpRequestFactory(Apache HttpClient 의존성 필요)로 전환을 고려해 보세요.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/main/java/com/example/inflace/global/config/RestClientConfig.java` at
line 17, Update RestClientConfig to replace SimpleClientHttpRequestFactory with
a connection-pooling request factory, preferably JdkClientHttpRequestFactory or
HttpComponentsClientHttpRequestFactory, and configure the corresponding client
while preserving the existing RestClient behavior.

---

12-23: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

타임아웃 값을 application.yml로 외부화하는 것을 권장합니다.

이 PR은 Resilience4j Bulkhead/RateLimiter 설정을 application.yml에 외부화하면서 "운영 부하에 따라 제한 값을 조정할 수 있다"는 목표를 밝히고 있습니다. 하지만 RestClient의 connect/read 타임아웃은 상수로 하드코딩되어 있어, 운영 중 타임아웃 조정 시 재배포가 필요합니다. Resilience4j 설정과 일관성 있게 @Value 또는 @ConfigurationProperties로 주입하는 것이 좋습니다.

♻️ 제안: application.yml 기반 타임아웃 주입

+import org.springframework.beans.factory.annotation.Value;
+
 `@Configuration`
 public class RestClientConfig {
 
-    private static final Duration CONNECT_TIMEOUT = Duration.ofSeconds(2);
-    private static final Duration READ_TIMEOUT = Duration.ofSeconds(5);
+    `@Value`("${rest-client.connect-timeout:2s}")
+    private Duration connectTimeout;
+
+    `@Value`("${rest-client.read-timeout:5s}")
+    private Duration readTimeout;
 
     `@Bean`
     public RestClient restClient() {
         SimpleClientHttpRequestFactory requestFactory = new SimpleClientHttpRequestFactory();
-        requestFactory.setConnectTimeout(CONNECT_TIMEOUT);
-        requestFactory.setReadTimeout(READ_TIMEOUT);
+        requestFactory.setConnectTimeout(connectTimeout);
+        requestFactory.setReadTimeout(readTimeout);
 
         return RestClient.builder()
                 .requestFactory(requestFactory)
                 .build();
     }
 }

application.yml에 추가:

rest-client:
  connect-timeout: 2s
  read-timeout: 5s

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/main/java/com/example/inflace/global/config/RestClientConfig.java` around
lines 12 - 23, Update RestClientConfig.restClient to read connect and read
timeout values from application.yml instead of the hardcoded CONNECT_TIMEOUT and
READ_TIMEOUT constants, using `@Value` or a dedicated `@ConfigurationProperties`
binding for the rest-client settings. Preserve the existing
SimpleClientHttpRequestFactory configuration while allowing both durations to be
changed through external configuration.